In #7638 I created a useMergedRefs hook and migrated all instances of useRefObjectAsForwardedRef to it.

A similar pattern is using useProvidedRefOrCreate for this. It's typically used with a type cast and a ts-expect-error comment (❗):

const ref = useProvidedRefOrCreate(forwardedRef as RefObject<HTMLElement | null>)

// @ts-expect-error
return <div ref={ref} />

This is obviously problematic. The type errors are trying to point out the problem with this pattern: it will break if consumers pass ref callbacks. Ref callbacks are likely to become more and more common as React 19 has introduced ref callback cleanup functions, making ref callbacks a viable alternative to effects.

A much better pattern is to be consistent and use the same approach as in #7638:

const ref = useRef<HTMLElement>(null)
const combinedRef = useCombinedRefs(ref, forwardedRef)

return <div ref={combinedRef} />

Note, however, that I did not deprecate useProvidedRefOrCreate or remove all calls to it. There are still some valid use cases where refs can be passed in to refer to elements rendered outside the component. We most often see this in anchor refs. There are also some utility hooks that can create a ref internally or use a passed ref. These two cases are still valid; the case I'm targeting here is specifically around forwarded refs.

• Stacks on Update useMergedRefs to be React 19 compatible and public + deprecate useRefObjectAsForwardedRef and useProvidedRefOrCreate #7672

Changelog

New

Changed

Removed

Rollout strategy

• Patch release
• Minor release
• Major release; if selected, include a written rollout or migration plan
• None; if selected, include a brief description as to why

Testing & Reviewing

Merge checklist

• Added/updated tests
• Added/updated documentation
• Added/updated previews (Storybook)
• Changes are SSR compatible
• Tested in Chrome
• Tested in Firefox
• Tested in Safari
• Tested in Edge
• (GitHub staff only) Integration tests pass at github/github-ui (Learn more about how to run integration tests)